I think "It is expected (to be confirmed) to remove this exception for the transform in the next version of the bitstream." should be removed. I dont think its expected

I understood it as a bug, because current spec is about JPEG2000-RCT everywhere, and I did not see such transform (G and B inverted compared to JPEG2000-RCT) elsewhere.
If this is not a bug and something intended, we need to be clear about:

• the reason another transform (not JPEG2000-RCT) is used. As I don't understand the reason if it is not a bug, I need help about explaining why we definitely (not changed in future version) choose a different transform depending of bits_per_raw_sample
• when JPEG2000-RCT applies and when something else applies. what is expected for bit depth not yet in FFmpeg encoder/decoder? e.g. for 555 RGB is it expected JPEG2000-RCT or the other one? for let say 30 bit per component is it expected JPEG2000-RCT or the other one? for 32? For the moment, I don't see any clear logic based on technical reasons (it could be JPEG2000-RCT "for <=8 and >=16", but it could also be "for multiples of 8"). For the moment this is "for <=8 and >=16" in my patch, but we need to be clear about it in case another encoder/decoder implements more bit depths before FFmpeg.

And if it is intended and planned to be kept, maybe we need to find another name for this colorspace_type, because "JPEG2000-RCT" is misleading in that case (this is JPEG2000-RCT only in some cases, depending of bit depth). On our side we used "JPEG2000-RCT" everywhere (JPEG 2000 explaination does not talk about difference depending of bit depth), as described in current FFV1 specs, and had issues with colors because it is actually not "JPEG2000-RCT" everywhere.
In that case, we need to change colorspace_type definition, currently set to "JPEG2000-RCT" in case colorspace_type== 1. Maybe "RCT" alone, and we define it as "JPEG2000-RCT" and "" (to be defined) depending of bits_per_raw_sample?

I am in favor to have a version 4 more coherent, and same transform for colorspace_type == 1 whatever is the bit depth, not a transform with a formula depending of both colorspace_type and bits_per_raw_sample, so I am in favor of keeping this sentence. I understood this is also the idea of @lu-zero (to be confirmed).
if the other transform is needed, maybe colorspace_type== 2 signaling?

It is a bug of course, we might solve this by replacing the JPEG2000-RCT (with bug) by a more efficient transform for example or we might leave it and fix the bug. I dont think its correct to say we expect that JPEG2000 RCT without bug will be the transform in the next version. Maybe it feels nitpickish but i think we shouldnt write in the spec an expect a specific solution in this case

Could we say something like this instead?

Methods to address this exception for the transform are under consideration for the next version of the bitstream.

It warns the present implementer that we may make a change but does not make it seem as if we already have consensus on how. IMHO we should split the discussions: one to document the present incoherency in plane order and a different one to consider the options to improve on this in a later version.

Still I want to ensure that we have consensus on the JPEG2000-RCT transforms with bits <8 and >16. From the current reading the exception applies only to the 9-15 range, so if another user implements a rgb555 that it should not use this exception.

Could we say something like this instead?

Methods to address this exception for the transform are under consideration for the next version of the bitstream.

I second this form.

I changed Jerome's:

It is expected (to be confirmed) to remove this exception for the media predictor in the next version of the bitstream.

to

Methods to address this exception for the transform are under consideration for the next version of the bitstream.

and force updated. Please re-review.

ping

I’m OK with the formulation, even if I would have preferred to resolve now the exception by a more efficient transform (but that’s just me).